1. Field of Invention
The present invention relates generally to the field of wireless communication systems. More particularly, in one exemplary aspect, the present invention is directed to the transmission of emergency or similar call data within a wireless network.
2. Description of Related Technology
Digital wireless systems such as e.g., cellular mobile communication systems, offer both real-time and non-real-time services to a user. Examples of real-time services include for example voice telephony calls and video telephony calls, while non-real-time services include various types of messaging services (e.g. SMS, MMS, e-mail) or presence services (e.g., “chat”). Digital cellular mobile communication can be realized either in a circuit switched network architecture (CS domain), or in a packet switched network architecture (PS domain). CS domain calls require a “circuit” or continuous connection to be created before a user data exchange can occur; e.g., to exchange digital voice data. Circuit switched networks connect one terminal through the mobile cellular network(s) and the CS domain core (backbone) network to another terminal. The connection establishment is performed between the involved network elements via various known control protocols. Once the connection is established, the digital user data transmitted by one terminal to the cellular mobile network is transported along the connection route through the network to the other terminal. Circuit Switched paths remain unchanged for the duration of the connection; no modifications can be made mid-call to alter the routing of the call.
PS domain calls (such as e.g., VoIP calls) do not have “hard connectivity” like CS domain calls. Instead, PS domain calls are routed flexibly on a network level; the underlying transport route is not pre-defined and may dynamically change. PS domain calls are packetized and transferred piecemeal through a “cloud” of network elements; therefore, every data packet comprises a routable Network Address (e.g. Internet Protocol or IP address) of both the source and destination terminals. A typical implementation of a packet switched network may embed Internet Protocol (IP) routing information within each transmitted data packet. This routing is commonly referred to as IP-routing. From a network level, IP-routing is connection-less; however, PS-domain calls may need (and typically perform) connection establishment on an application/session layer before data transfer to negotiate various parameters such as type, quality, format, coding of the exchanged data and/or quality, bandwidth as well as other parameters of the underlying transport streams.
CS and PS domains have several distinct differences directly related to their structure and method of operation. As noted above, CS domain calls maintain a “fixed” circuit throughout operation; therefore, a CS call has a reasonably consistent timing (because the data transmission follows the same route with fixed transmission parameters) for its data transmissions within certain tolerances. Furthermore, a CS call is naturally linear; each transmission sequentially follows its predecessor. A PS domain call differs significantly from the CS domain model due to the flexible routing of the packets to their destination, irregular bandwidth or capacity, and varying delay of the set of hops the data is routed along. Thus the timing and delay associated with the data packets varies over a wide range for a PS call. Accordingly, data packets that carry real-time data such as voice or video data are normally embedded in a protocol that enables the extraction of timing information.
For instance, the commonly used Real Time Transport Protocol (RTP) contains, inter alia, such timing information and is commonly used for real time voice and video data transmission within PS domains of a cellular mobile network. Both the RTP and RTCP are intended for use within systems that handle broader transport layer requirements, such as addressing, error detection and/or error correction mechanisms. The most commonly used protocols into which RTP and RTCP packets are embedded are the User Datagram Protocol (UDP) and the Transport Control Protocol (TCP). Among other differences, TCP offers reliable transport and QoS (quality of service) with error correction mechanisms, whereas UDP does not offer such guarantees. The additional functionality of TCP requires more messaging overhead, as well as “state memory” within network components. UDP is simpler and more efficient, but can be lossy and irregular depending on its bearer. UDP does not require any handshaking to transmit or receive a segment, thus UDP may also be generally categorized as “connectionless”. RTP is typically used in combination with UDP, as the two protocols have complementary features. In most use cases, the additional reliability of TCP would be wasted on RTP; the additional time required to ensure accurate delivery would negate any benefits of error correction (late packets are discarded in most RTP systems).
Emergency and Other High Priority Calls
Normal services in cellular mobile networks (such as a voice call) are established only under certain acceptance pre-conditions. These pre-conditions may include: authentication of the user (as to identity), authorization of the user for particular services, checking the user's account status, and the ability or willingness of the operator to grant the required resources to the user. Depending upon the conditions present within the network, as well as the status of a mobile terminal with regards to pre-conditions (e.g. authentication, authorization, and accounting), call establishment times may be delayed or the call may be rejected altogether. In the case of a high priority call (e.g., an emergency call placed to request emergency services assistance, such as fire, medical emergency or police), the emergency call may be given a higher priority handling to prevent any delay or hindrance.
An emergency call may either be requested or detected; either the terminal indicates in the call establishment request that it wants to establish an emergency call, or alternatively the network may determine that the destination address is a request for emergency services (e.g. by a user dialing 911, etc.). In either situation, after having received the request to setup an emergency call, the network treats the request with high priority, and expedites processing. In addition to establishing the emergency call, it is possible that the network may initiate other procedures to provide the termination point with additional information about the originator of the emergency call (such as geographical location, etc.). Many cellular networks have defined “Emergency Calls” that can be established with a minimum set of pre-conditions (e.g. by obviating the need for the user to be authenticated, etc.).
ECalls and Enhanced 911 (E911)
According to various guidance from relevant standards bodies and government authorities, another class of emergency communications comprises so-called “eCalls” (Europe) or Enhanced 911 calls (North America), the latter which further includes Wireless E911 and VoIP E911. See, e.g., the European Commission Memorandum of Understanding entitled “Memorandum of Understanding for Realisation of Interoperable In-Vehicle eCall”, eSafety Forum and eCall Driving Group, dated May 28, 2004 and related implementation standards, incorporated herein by reference in its entirety, which describe European eCall systems.
For example, under the aforementioned European system, an eCall is an emergency call from an In-Vehicle System (IVS) generated either manually by the occupants of the vehicle, or automatically by the IVS, after the detection of an event such as an automobile accident. The eCall is sent from the IVS, across a 2nd Generation (2G) or 3rd Generation (3G) mobile network, to a Public Safety Answering Point (PSAP). Together with the emergency call, a Minimum Set of Data (MSD) is transmitted to the PSAP that describes the relevant situation; e.g., information automatically generated by or derived from the automobile. Information given in the MSD may comprise a high-accuracy location of the car (typically measured with a built-in Global Navigation Satellite System (GNSS) transceiver), the number of occupants, whether or not the car has turned over as a result of the accident, etc. Note that prior art implementations of the initial eCall or E911 service operate in the CS domain.
The format of the exemplary MSD is illustrated in FIG. 1. As can be seen, the size of the MSD 100 may vary as a portion of the information elements within the MSD are optional. Specifically, the content of the Optional Data field 102 is only required to be Extensible Markup Language (XML) code; the length of the field is allowed to vary within a prescribed range. However, the maximum data size for the MSD 100 is one-hundred forty (140) bytes.
Another alternative to the MSD is a Full Set of Data (FSD) that may be sent if the underlying transport mechanisms allow a larger size of eCall data to be transmitted. Hence, as used herein, the term “eCall data” refers to an MSD, FSD or any other data that is transmitted (which may be in concert with the voice data) within an eCall connection.
Several potential options exist for the transmission of data (such as for example MSD or FSD). These options include: (i) Short Message Service (SMS); (ii) User to User Signaling (UUS); (iii) Unstructured Supplementary Service Data (USSD); (iv) Global Systems for Mobile communications (GSM) CS Data; (v) Dual-Tone Multi-Frequency (DTMF); and (vi) In-band modem/Signaling Application. However, these solutions fail to provide adequate capability to transport a minimum set of data in combination with an emergency call in a timely fashion, and without redirection or rerouting on a packet switched network. Consequently, improved apparatus and methods are needed which would address these deficiencies.